Resource Search Results

Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients (2019). Resource Type: Publication. Description: Cyber threats to healthcare entities put patient health, business continuity, and IT systems at risk. Under the auspices of the Cybersecurity Act of 2015 (CSA), Section 405(d), HHS convened the CSA 405(d) Task Group to enhance cybersecurity and align industry approaches by developing a common set of voluntary, consensus-based, and industry-led guidelines, practices, methodologies, procedures, and processes that healthcare organizations can use to enhance cybersecurity. More Details...

Creating and Managing Strong Passwords at Your Health Center: Guidance in relation to updated NIST security requirements and HIPAA (2018). Resource Type: Publication. Description: Is it acceptable/recommended for health centers to adopt the new password policy guidelines under NIST Special Publication 800-63B and will that still uphold the HIPAA security rule? This question had been posed to the HITEQ Center asking whether we had any guidance or recommendations on implementing the new NIST Guidelines regarding password security.  New Digital Identity Guidelines under NIST Special Publication 800-63-B presents new guidelines regarding password security that are much more user-friendly and consequently more likely to be observed by health center staff since constantly changing, complex password on multiple systems can be a source of frustration for the end user.  Question: Is it acceptable/recommended for health centers to adopt the new password policy guidelines under NIST Special Publication 800-63B and will that still uphold the HIPAA security rule? This question had been posed to the HITEQ Center asking whether we had any guidance or recommendations on implementing the new NIST Guidelines regarding password security.  New Digital Identity Guidelines under NIST Special Publication 800-63-B presents new guidelines regarding password security that are much more user-friendly and consequently more likely to be observed by health center staff since constantly changing, complex password on multiple systems can be a source of frustration for the end user.  After consulting with HITEQ cybersecurity experts and consultants who have helped publish cybersecurity guidelines, the recommendations outlined below were communicated. Answer: The short answer is Yes. HIPAA is not prescriptive and takes the general stance that authentication mechanisms should be “reasonable and appropriate” for the risk they present. Being able to say that you are implementing NIST Standards is a good way to show that you are implementing “reasonable and appropriate” controls. Some standards are relaxed in regards to password change and complexity, those items shouldn’t be taken in isolation. The additional controls in the 800-63 recommendations should also be put in place and can include: Having users check passwords against password lists from breaches e.g., https://haveibeenpwned.com/Passwords  Increasing the length requirements Getting rid of password reminder questions Increasing usability Further Guidance from NCCIC/US-CERT: NCCIC/US-CERT reminds users of the importance of creating and managing strong passwords. Passwords are often the only barrier between you and your personal information. There are several programs attackers can use to help guess or "crack" passwords. However, choosing strong passwords and keeping them confidential can make it more difficult for others to access your information. NCCIC/US-CERT recommends users take the following actions: Use multi-factor authentication when available. Use different passwords on different systems and accounts. Don't use passwords that are based on personal information that can be easily accessed or guessed. Use the longest password or passphrase permissible by each password system. Don't use words that can be found in any dictionary of any language. Refer to Tips on Choosing and Protecting Passwords and Supplementing Passwords for best practices and additional information. More Details...

42 CFR Part 2 Final Rule and Health Center Compliance: A HITEQ Webinar in collaboration with the California Primary Care Association (CPCA) (2017). Resource Type: Publication. Description: This presentation explored the history and recent changes of 42 CFR Part 2, review common definitions, and how the changes may affect integrated medication-assisted treatment (MAT) and Screening, Brief Intervention, and Referral to Treatment (SBIRT) programs, and discussion on LifeLong Medical Care’s experience. More Details...

Security Risk Assessment: A HITEQ Privacy & Security Resource - New Templates Added May 2017 (2017). Resource Type: Template. Description: To successfully attest, providers must conduct a security risk assessment (SRA), implement updates as needed, and correctly identify security deficiencies. By conducting an SRA regularly, providers can identify and document potential threats and vulnerabilities related to data security, and develop a plan of action to mitigate them. More Details...

Breach Protection Overview Presentation for Health Centers: A HITEQ Privacy & Security Resource (2017). Resource Type: Publication. Description: Data breaches in healthcare are consistently high in terms of volume, frequency, impact, and cost. High-level breaches are increasingly occurring in a more targeted manner toward health centers. This presentation provides Health Center leadership and trainers with a template to use to build out their own organization-specific presentation on breach. Data breaches in healthcare are consistently high in terms of volume, frequency, impact, and cost. High-level breaches are increasingly occurring in a more targeted manner toward health centers. This presentation provides Health Center leadership and trainers with a template to use to build out their own organization-specific presentation on breach. This presentation template covers the following agenda: Quick Start Healthcare Privacy & Security Healthcare Privacy & Security Policies and Legislation Implications for Breach Management and Mitigation Strategies Questions and discussion More Details...

Encrypting Data at Rest on Servers: Implications for Health Centers (2016). Resource Type: Publication. Description: It is common practice today to encrypt data at rest, that is, data stored on servers. This is especially applicable to health centers who are less frequently actively transporting data across disparate networks. Like many smaller healthcare organizations, Health Centers are particularly vulnerable to potential attack and infiltration by data hackers for several reasons: they tend to have fewer technical support staff, resource limitations make it harder to assess, implement, and maintain safe data practices, and organizational inertia limits preventive action when no threat is perceived.  It is common practice today to encrypt data at rest, that is, data stored on servers. Like many smaller healthcare organizations, Federally Qualified Health Centers FQHC are particularly vulnerable to potential attack and infiltration by data hackers for several reasons: they tend to have fewer technical support staff, resource limitations make it harder to assess, implement, and maintain safe data practices, and organizational inertia limits preventive action when no threat is perceived. To build off an old adage, no one ever got fired for encrypting their data. But what protection does that really provide? Is just encrypting data enough? First, let’s distinguish between three methods for encrypting data at rest. Full-disk encryption. Most modern operating systems like Linux or Windows Server provide the capability to encrypt their disks in their entirety. This is accomplished with symmetric encryption whereby there is a key or passphrase that a computer operator has to enter when the disks are encrypted and when the system boots to allow access to the data. Typically, the password must be manually entered on the physical server console, though some virtualized and cloud-based environments offer remote passphrase entry and varying degrees of passphrase management and automation. With full-disk encryption, software installed on the server does not need to know or do anything special to operate normally: the operating system provides transparent access to the encrypted data as necessary with very little performance loss. But note that the initial encryption needs to be done on a new disk or set of disks as an existing disk will be wiped clean in the process. So it’s easiest to do this during an initial deployment or migration to a new server. File system encryption. Physical disks are typically divided into one or more file systems by the operating system.  As an alternative to full-disk encryption, file system encryption allows administrators to encrypt only selected file systems or even just selected folders within file systems. This makes it possible to configure a server than can boot without a passphrase; and then require a passphase only after the system is up and running and needs to access its encrypted file systems.  Similar to full-disk encryption, the encryption is transparently provided to applications by the operating system.  Unlike full-disk encryption, developers and administrators need to be careful not to store sensitive files on non-encrypted file systems. Database encryption.  Another way to encrypt data at rest is at the database level: The database software Oracle, SQL Server can provide application-level encryption. Like operating system level encryption, a key or passphrase is entered by an operator when the database starts up, after which all database operations access the encrypted data transparently hence the name: Both Oracle and Microsoft SQL Server call the feature “Transparent Data Encryption”. For servers that may store sensitive data in files outside the database, this provides less protection than encrypting the entire file system, but likely protects the most sensitive data on the system. What kind of protection does encrypting data at rest really provide? Here are a few salient points: Benefits of Encrypting Data at Rest First and foremost, encrypting data at rest protects the organization from the physical theft of the file system storage devices which is why end-user mobile devices from laptops to cell phones should always be encrypted. While this might sound unlikely, the physical disk devices are only as secure as the data center where they are located. While data center access control policy is usually quite strict, in practice it can be quite lax. Door entry can employ weak precautions like old push-button unlock devices, and the proliferation of easily-swappable modular disks for quick maintenance makes removing a disk quite easy. Encrypting data at rest can protect the organization from unauthorized access to data when computer hardware is sent for repair or discarded. Encrypting data at rest can help to satisfy information security or regulatory requirements such as the Payment Card Industry Data Security Standard PCI DSS or the Health Insurance Portability and Accountability Act HIPAA. In some deployments, the actual file system where data resides is somewhat disconnected from the server upon which applications are loaded either through the use of a storage area network SAN or cloud-based storage. This introduces the possibility that an intruder could break in to the storage subsystem but not the rest of the system. Encrypting the storage subsystem can protect against such attacks. Limitations of Encrypting Data at Rest Encryption of data at rest provides little protection against intrusions in which a hacker gains remote privileged access to a running server in which the passphrase has already been entered. Even more so, if the applications that access the encrypted files or databases web applications, query systems are not themselves secured, a hacker who penetrates one of these applications gains access to the data, whether it is encrypted or not. For database encryption, note that some database management systems only support data encryption in more advanced read more expensive versions of the software. When full-disk encryption is enabled on a physical non-virtualized server, remember that an operator – a human being – will need to type the passphrase into a console whenever the system starts up. For database-level encryption, the passphrase will need to be entered when the database starts up. While this intervention increases the level of protection, it is at the expense of convenience, as systems cannot reboot automatically without a passphrase or even without someone actually being in the server room which can be especially inconvenient if the system manager is not collocated with the hardware. File system encryption can mitigate some of these startup issues. And, of course, if that passphrase is ever lost your data will be encrypted forever. Special Considerations for Virtualized and Cloud-based Environments As mentioned, some virtualized and cloud-based environments offer remote passphrase entry and varying degrees of passphrase management and automation for full-disk encryption – but be aware that there is often a tradeoff between convenience and security with automated solutions. For example, if a cloud provider keeps your passphrase and automatically provides it to the operating system at boot time, the level of security offered by the full-disk encryption solution is largely dependent on how securely the cloud provider manages the passphrase. While encrypting data at rest can be a useful component in a data security toolbox, it must be implemented with a full understanding of the protection it does and does not provide. Organizations should consult with their vendors, data security staff, system staff, and application staff to determine an appropriate set of actions to secure institutional data. More Details...